---
theme: gaia
_class: lead
paginate: true
backgroundColor: #fff
marp: true
math: mathjax
---

<style>
img[alt~="center"] {
  display: block;
  margin: 0 auto;
}
code {
    background: #000;
}
pre {
    background: #000;
}
</style>

# Автоматизация разработки и эксплуатации ПО

<style scoped>
h1 {
    font-size: 1.5rem;
}
h2 {
    font-size: 1rem;
}
</style>

![bg left:40% 80%](../images/iu5edu_logo.jpg)

## Контроль версий, Git, CI/CD

**Аладин** Дмитрий Владимирович

[iu5edu.ru/wiki/devops/](https://iu5edu.ru/wiki/devops/)

---

# План

1. Контроль версий.
2. Git.
3. CI/CD.
4. Рабочие процессы.
5. Сервисы хранения репозиториев исходного кода.

---

# Контроль версий и системы контроля версий

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.75rem;
}
</style>

![bg left:50% 90%](images/version-control.jpg)

**Контроль версий** (англ. *version control*), также известный как контроль исходного кода (англ. source control), - это практика отслеживания и управления изменениями в программном коде.

**Системы контроля версий** (англ. *version control systems*, VCS) - это программные инструменты, которые помогают группам разработчиков управлять изменениями исходного кода с течением времени.

---

Программное обеспечение для контроля версий является **неотъемлемой частью повседневной профессиональной деятельности** современной команды разработчиков программного обеспечения.

*Настоящая система отслеживания изменений*:

![height:280px center](images/new-directory-meme.jpg)

---

# Преимущества систем контроля версий

<style scoped>
h1 {
    font-size: 1.1rem;
}
li {
    font-size: 0.9rem;
}
</style>

1. **Полная долгосрочная история изменений каждого файла**. Это означает, что имеется полная история изменения файла, когда-либо внесенными любым членом команды в любой момент.
2. **Ветвление и слияние**. Наличие одновременной работы нескольких членов команды не составляет труда, но даже люди, работающие самостоятельно, могут извлечь выгоду из возможности работать с независимыми потоками изменений.
3. **Отслеживаемость**. Возможность отслеживать каждое изменение, внесенное в программное обеспечение, и подключать его к программному обеспечению для управления проектами и отслеживания ошибок.

---

<style scoped>
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

![bg right:47% 75%](images/git-gud.jpg)

Контроль версий позволяет получить:

- **Качество**. Команды могут просматривать, комментировать и улучшать код и ресурсы друг друга.
- **Ускорение**. Быстрее распределяется работа, вносятся изменения и объединяются результаты изменений.
- **Видимость**. Понимание и стимулирование совместной работы команды для улучшения шаблонов сборки и выпуска версий.

---

# Управление исходным кодом

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg left:55% 97%](images/scm.jpg)

**Управление исходным кодом** (англ. *source control management*, SCM) используется для отслеживания изменений в репозитории исходного кода. SCM отслеживает текущую историю изменений в базе кода и помогает разрешать конфликты при объединении обновлений от нескольких участников.

---

# Репозиторий

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg right:55% 90%](images/repository.jpg)

— место, где **хранятся** и **поддерживаются какие-либо данные**. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети.

— каталог файловой системы, в котором могут находиться файлы **журналов конфигураций** и **операций**, выполняемых над репозиторием, а также сами контролируемые файлы.

---

# Важность инструментов управления исходным кодом

<style scoped>
h1 {
    font-size: 1.1rem;
}
</style>

![height:570px center](images/scm-and-company.svg)

---

# Преимущества управления исходным кодом

<style scoped>
h1 {
    font-size: 1.1rem;
}
li {
    font-size: 0.8rem;
}
</style>

- Архив SCM всех изменений за время существования проекта обеспечивает ценный **учет примечаний к выпускной версии проекта**. Чистый и поддерживаемый журнал истории SCM можно взаимозаменяемо использовать в качестве примечаний к выпуску. Это обеспечивает понимание и прозрачность хода выполнения проекта, которыми можно поделиться с конечными пользователями или командами, не занимающимися разработкой.
- SCM **сокращает коммуникационные издержки команды и увеличит скорость выпуска**. Без SCM разработка идет медленнее, потому что участникам приходится прилагать дополнительные усилия для планирования непересекающейся последовательности разработки для выпуска. С помощью SCM разработчики могут независимо работать над отдельными разделами разработки функций, в конечном итоге объединяя их вместе.

---

<style scoped>
li {
    font-size: 0.8rem;
}
p {
    font-size: 0.8rem;
}
</style>

Вернемся к VCS. VCS даёт возможность:

- возвращать отдельные файлы к прежнему виду;
- возвращать к прежнему состоянию весь проект;
- просматривать происходящие со временем изменения;
- определять, кто последним вносил изменения во внезапно переставший работать модуль, кто и когда внёс в код какую-то ошибку.

Можно просто копировать проект в другой каталог, такой подход часто применяется из-за своей простоты, но имеет множество недостатков:

- избыточность (дублируется весь код, а не только изменения);
- нет механизмов для распределения работы между несколькими разработчиками;
- нет данных о том что именно изменилось (обычно пишут history файл с общей информацией об изменениях).

---

# Локальные системы контроля версий

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg left:50% 90%](images/lvcs.png)

Одной из наиболее известных VCS такого типа является [rcs](https://www.gnu.org/software/rcs/) (Revision Control System). Эта утилита основана на работе с наборами патчей между парами версий (патч — файл, описывающий различие между файлами), которые хранятся в специальном формате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи.

---

# Централизованные системы контроля версий

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg right:50% 90%](images/cvcs.png)

В таких систем, как [Apache Subversion](https://subversion.apache.org/) и [Perforce Helix](https://www.perforce.com/products/helix-core), есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него.

---

# Распределённые системы контроля версий

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

В таких системах как [Git](https://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), [Bazaar](http://bazaar.canonical.com/en/) или [Darcs](http://darcs.net/) клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий (репозиторий, в простонародье репа, это место, где хранятся и поддерживаются какие-либо данные).

![bg left:50% 90%](images/dvcs.png)

---

# Локальные VCS (+/-)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.7rem;
}
li {
    font-size: 0.7rem;
}
</style>

Преимущества:

1. Позволяет хранить историю изменения файлов локально, без интернета.
2. Вы независимы от сторонних серверов.

Недостатки:

1. Вы можете потерять все файлы, если с вашем компьютером что-то случится.
2. Вы не можете работать в команде, поскольку репозиторий доступен только вам.

---

# Централизованные VCS (+/-)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.7rem;
}
li {
    font-size: 0.7rem;
}
</style>

Преимущества:

1. Вы можете работать в команде с другими разработчиками.
2. Ваше начальство видит, чем вы занимаетесь.
3. У администратора есть четкий контроль, кто и что может делать. Администрировать центральную VCS намного проще, чем локальные на каждой машине.

Недостатки:

1. Все данные хранятся только на одном сервере. Если он выключится, то работу всей компании парализует.
2. Если с сервером что-то случится, а копий данных нет, то весь проект может быть потерян.
3. Для работы необходим хороший интернет на протяжении целого дня.

---

# Распределенные VCS (+/-)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.7rem;
}
li {
    font-size: 0.7rem;
}
</style>

Преимущества:

1. Работа компании теперь не зависит от работы сервера. Если сервер отключится, то каждый сотрудник продолжит работу с локальной копией репозитория, а после загрузит ее на сервер.
2. Можно работать с несколькими удаленными репозиториями, делиться кодом с другими людьми и коллаборировать целыми компаниями.

Недостатки:

1. Отсутствие блокировок.
2. Неудобства при работе с большими репозиториями.
3. Сложно полностью удалить что-то из репозитория.
4. Сложное администрирование.
5. Сложнее в использовании и понимании, чем централизованные системы.

---

# ПО для VC: Git

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
</style>

![bg right:50% 90%](images/gitk.png)

[Git](https://git-scm.com/) является самым популярным вариантом и стал синонимом "управления исходным кодом".

---

# ПО для VC: Subversion

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
</style>

![bg left:50% 90%](images/svn-gui.png)

[Subversion](https://subversion.apache.org/) - это широко распространенная централизованная система контроля версий. Эта система хранит все файлы проекта в одной кодовой строке, что делает невозможным ветвление, поэтому ее легко масштабировать для больших проектов.

---

# ПО для VC: Mercurial

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
</style>

![bg right:50% 90%](images/mercurial-gui.png)

[Mercurial](https://www.mercurial-scm.org/) - это распределенная система контроля версий, которая предлагает простые возможности ветвления и объединения. Система обеспечивает быстрое масштабирование и совместную разработку с интуитивно понятным интерфейсом.

---

# Краткая история Git

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg right:50% 215%](images/torvalds.png)

В 2005 году отношения между сообществом разработчиков ядра Linux и коммерческой компанией, которая разрабатывала BitKeeper, прекратились, и бесплатное использование утилиты стало невозможным. Это сподвигло сообщество разработчиков ядра Linux (а в частности Линуса Торвальдса — создателя Linux) разработать свою собственную утилиту, учитывая уроки, полученные при работе с BitKeeper.

---

Некоторыми целями, которые преследовала новая система, были:

- Скорость
- Простая архитектура
- Хорошая поддержка нелинейной разработки (тысячи параллельных веток)
- Полная децентрализация
- Возможность эффективного управления большими проектами, такими как ядро Linux (скорость работы и разумное использование дискового пространства)

Так и получился Git в 2005 году.

---

# Отличительные особенности Git

<style scoped>
h1 {
    font-size: 1.2rem;
}
h2 {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
</style>

## Снимки, а не различия

Основное отличие Git от любой другой системы контроля версий (включая Subversion и её собратьев) — это **подход к работе со своими данными**. Концептуально, большинство других систем хранят информацию в виде **списка изменений в файлах**. Эти системы (CVS, Subversion, Perforce, Bazaar и т. д.) представляют хранимую информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени (обычно это называют контролем версий, основанным на различиях).

---

*Хранение данных как набора изменений относительно первоначальной версии каждого из файлов*:

![height:400px center](images/deltas.png)

---

Подход Git к хранению данных больше похож на **набор снимков** миниатюрной файловой системы. *Хранение данных как снимков проекта во времени*:

![height:400px center](images/snapshots.png)

---

# Отличительные особенности Git

<style scoped>
h1 {
    font-size: 1.2rem;
}
h2 {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
</style>

## Потенциальные проблемы Git-репозитория

Каждый раз, когда вы **делаете коммит**, то есть сохраняете состояние своего проекта в Git, система **запоминает**, как выглядит каждый файл в этот момент, и **сохраняет ссылку на этот снимок**.

Для увеличения эффективности, если файлы не были изменены, Git не запоминает эти файлы вновь, а только создаёт ссылку на предыдущую версию идентичного файла, который уже сохранён. Git представляет свои данные как, скажем, поток снимков.

---

# Отличительные особенности Git

<style scoped>
h1 {
    font-size: 1.2rem;
}
h2 {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
</style>

## Почти все операции выполняются локально

Для работы большинства операций **в Git достаточно локальных файлов и ресурсов** — в основном, системе не нужна никакая информация с других компьютеров в вашей сети.

Вся история проекта хранится прямо на вашем локальном диске, большинство операций кажутся чуть ли не мгновенными.

---

# Отличительные особенности Git

<style scoped>
h1 {
    font-size: 1.1rem;
}
h2 {
    font-size: 0.9rem;
}
p {
    font-size: 0.9rem;
}
</style>

## Целостность Git

В Git для всего вычисляется хеш-сумма, и только потом происходит сохранение. В дальнейшем обращение к сохранённым объектам происходит по этой хеш-сумме. Это значит, что невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом.

Механизм, которым пользуется Git при вычислении хеш-сумм, называется SHA-1 хеш. Это строка длиной в 40 шестнадцатеричных символов (0-9 и a-f), она вычисляется на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:

```bash
24b9da6552252987aa493b52f8696cd6d3b00373
```

---

*Является ли репозиторий Git блокчейном?*

![height:500px center](images/git-sha-example.png)

---

# Отличительные особенности Git

<style scoped>
h1 {
    font-size: 1.2rem;
}
h2 {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
</style>

## Git обычно только добавляет данные

Когда вы производите какие-либо действия в Git, практически все из них только добавляют новые данные в базу Git. Очень сложно заставить систему удалить данные либо сделать что-то, что нельзя впоследствии отменить.

Как и в любой другой VCS, вы можете потерять или испортить свои изменения, пока они не зафиксированы, но после того, как вы зафиксируете снимок в Git, будет очень сложно что-либо потерять, особенно, если вы регулярно синхронизируете свою базу с другим репозиторием.

---

# Отличительные особенности Git

<style scoped>
h1 {
    font-size: 1.2rem;
}
h2 {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 1rem;
}
</style>

## Три состояния

У Git есть три основных состояния, в которых могут находиться ваши файлы: изменён (*modified*), индексирован (*staged*) и зафиксирован (*committed*):

- К **изменённым** относятся файлы, которые поменялись, но ещё не были зафиксированы.
- **Индексированный** — это изменённый файл в его текущей версии, отмеченный для включения в следующий коммит.
- **Зафиксированный** значит, что файл уже сохранён в вашей локальной базе.

---

<style scoped>
p {
    font-size: 0.85rem;
}
li {
    font-size: 0.85rem;
}
</style>

Три основные секциям проекта Git: *рабочая копия* (working tree), *область индексирования* (staging area) и *каталог Git* (Git directory). Подробнее остановимся на секциях:

- **Рабочая копия** является снимком одной версии проекта. Эти файлы извлекаются из сжатой базы данных в каталоге Git и помещаются на диск, для того чтобы их можно было использовать или редактировать.
- **Область индексирования** — это файл, обычно находящийся в каталоге Git, в нём содержится информация о том, что попадёт в следующий коммит. Её техническое название на языке Git — "индекс", но фраза "область индексирования" также работает.
- **Каталог Git** — это то место, где Git хранит метаданные и базу объектов вашего проекта. Это самая важная часть Git и это та часть, которая копируется при клонировании репозитория с другого компьютера.

---

*Рабочая копия, область индексирования и каталог Git:*

![height:500px center](images/areas.png)

---

# Базовый подход в работе с Git

1. Изменяете файлы вашей *рабочей копии*.
2. Выборочно добавляете в индекс только те изменения, которые должны попасть в следующий коммит, добавляя тем самым снимки только этих изменений в *индекс*.
3. Когда вы делаете коммит, используются файлы из индекса как есть, и этот снимок сохраняется в ваш *каталог Git*.

---

# Базовые понятия (1)

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.9rem;
}
</style>

**Репозиторий** – папка проекта, отслеживаемого Git, содержащая дерево изменений проекта в хронологическом порядке. Все файлы истории хранятся в специальной папке `.git/` внутри папки проекта.

**Индекс** – файл, в котором содержатся изменения, подготовленные для добавления в коммит. Вы можете добавлять и убирать файлы из индекса.

**Коммит** – фиксация изменений, внесенных в индекс. Другими словами, коммит – это единица изменений в вашем проекте. Коммит хранит измененные файлы, имя автора коммита и время, в которое был сделан коммит. Кроме того, каждый коммит имеет уникальный идентификатор, который позволяет в любое время к нему откатиться.

---

# Базовые понятия (2)

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.85rem;
}
</style>

**Указатели** `HEAD`, `ORIG_HEAD` и т. д. – это ссылка на определенный коммит. **Ссылка** – это некоторая метка, которую использует Git или сам пользователь, чтобы указать на коммит.

**Ветка** – это последовательность коммитов. Технически же, ветка – это ссылка на последний коммит в этой ветке. Преимущество веток в их независимости. Вы можете вносить изменения в файлы на одной ветке, например, пробовать новую функцию, и они никак не скажутся на файлах в другой ветке. Изначально в репозитории одна ветка, но позже мы рассмотрим, как создавать другие.

**Рабочая копия** – Директория `.git/` с её содержимым относится к Git. Все остальные файлы называются рабочей копией и принадлежат пользователю.

---

# Настройки Git

<style scoped>
h1 {
    font-size: 1.1rem;
}
li {
    font-size: 0.85rem;
}
p {
    font-size: 0.85rem;
}
</style>

![bg right:50% 90%](images/git-config.png)

Изменить настройки Git можно двумя способами:

- **Отредактировать файл** `gitconfig` (на уровне системы) или `.gitconfig` (глобально) или `.git/config` (на уровне репозитория) напрямую, то есть используя текстовый редактор.
- **Воспользоваться утилитой `git config`**.

---

# Состояния файлов

<style scoped>
h1 {
    font-size: 1.1rem;
}
li {
    font-size: 0.8rem;
}
p {
    font-size: 0.8rem;
}
</style>

1. **Отслеживаемым** (*tracked*). Об этих файлах Git знает и отслеживает изменения в них. Отслеживаемые файлы в свою очередь могут находится в следующих состояниях:
   1. **Неизмененным** (*unmodified*). То есть с момента последнего коммита в файле не было никаких изменений
   2. **Измененным** (*modified*). То есть с последнего коммита в файле были произведены какие-то изменения.
   3. **Подготовленным к коммиту** (*staged*). Это значит, что вы внесли изменения в этот файл и затем проиндексировали их, и эти изменения будут добавлены в следующий коммит.
2. **Неотслеживаемым** (*untracked*). О неотслеживаемых файлах Git не знает, поэтому изменения в них не будут добавлены в коммит. Это любые файлы в вашем рабочем каталоге, которые не входили в последний коммит и не подготовлены к текущему коммиту.

---

Наглядная визуализация состояний и переходов между ними:

![height:450px center](images/git-file-statuses.png)

---

# Объекты Git

<style scoped>
h1 {
    font-size: 0.9rem;
}
li {
    font-size: 0.65rem;
}
p {
    font-size: 0.65rem;
}
</style>

![bg left:42% 90%](images/git-objects.png)

**Объект** – это файл, содержащий определенную информацию о репозитории и его файлах. Все объекты хранятся в директории `.git/objects/`. Объекты бывают трех типов:

- **Blob** (англ. binary large object) – большой бинарный объект, другими словами просто бинарный файл.
- **Tree** (англ. tree – дерево). Дерево – это такой тип графа. Объект дерева состоит из имен:
  - blob-объектов для файлов, которые лежат в данной директории, и
  - других деревьев для всех поддиректорий.
- **Объект коммита**. Этот объект содержит в себе имя автора коммита, время коммита и объект дерева корневой директории проекта.

---

Кроме этих трех объектов, важным во внутреннем устройстве Git является *файл индекса*.

**Индекс** – файл, в котором содержатся изменения, подготовленные для добавления в коммит. Во время добавления файлов командой `git add`:

1. Сжимает содержимое этого файла и создает blob-объект.
2. Записывает имя этого объекта в файл индекса.

---

# Файловая система Git и команды

<style scoped>
h1 {
    font-size: 0.9rem;
}
p {
    font-size: 0.7rem;
}
li {
    font-size: 0.7rem;
}
</style>

![bg right:65% 95%](images/areas-and-commands.jpeg)

- рабочая директория (файловая система вашего компьютера);
- область подготовленных файлов (staging area, хранит содержание следующего коммита);
- HEAD (последний коммит в репозитории).

---

# Файловая система Git и удаленный репозиторий

<style scoped>
h1 {
    font-size: 0.9rem;
}
p {
    font-size: 0.7rem;
}
li {
    font-size: 0.7rem;
}
</style>

![height:500px center](images/git_states_with_remote.jpg)

---

А теперь вспомним про преимущества распределённых систем контроля версий:

![height:500px center](images/distributed-version-control.jpg)

---

# Что такое методология CI/CD?

**CI/CD** (*Continuous Integration*, *Continuous Delivery* — непрерывная интеграция и доставка) — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчики, аналитики, инженеры качества, конечные пользователи и др.).

---

# Принципы CI/CD

<style scoped>
h1 {
    font-size: 1.2rem;
}
li {
    font-size: 1rem;
}
</style>

![bg left:50% 95%](images/it-hell.png)

- Сегрегация ответственности заинтересованных сторон.
- Снижение риска.
- Короткий цикл обратной связи.
- Реализация среды.

---

# Этапы CI/CD

<style scoped>
h1 {
    font-size: 1.2rem;
}
li {
    font-size: 1rem;
}
</style>

![height:500px center](images/ci-cd-flow.png)

---

# CI/CD и DevOps

<style scoped>
h1 {
    font-size: 1.2rem;
}
li {
    font-size: 1rem;
}
</style>

![height:500px center](images/devops-pipeline.png)

---

# Преимущества CI/CD

- Инструменты CI/CD позволяют **быстро выводить программный продукт на рынок**, исправлять ошибки, внедрять новую функциональность.
- Автоматизация позволяет снизить нагрузку на членов команды, облегчает тестирование и уменьшает количество ошибок в каждой итерации. Главный плюс — это **быстрая обратная связь**.
- Гибкий план позволяет **быстро перераспределять ресурсы** команды на решение действительно важных задач.

---

# Недостатки CI/CD

- Часто инструменты CI/CD воспринимаются как швейцарский нож, который может справиться с любыми задачами. При недостатке опыта это может приводить **к существенному усложнению процессов в команде**.
- Инструменты CI/CD не могут решить **проблемы взаимодействия внутри команды**, обо всём придётся договариваться.
- Все члены команды должны работать в единой экосистеме.

---

# [Инструменты для CI/CD](https://digital.ai/learn/devops-periodic-table/)

<style scoped>
h1 {
    font-size: 1.2rem;
}
li {
    font-size: 1rem;
}
</style>

![height:500px center](images/devops-periodic-table.png)

---

# Gitflow

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![height:500px center](images/gitflow.png)

---

# GitHub Flow

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![height:500px center](images/githubflow.jpg)

---

# GitLab Flow

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![height:530px center](images/gitlabflow.png)

---

# Сравнение рабочих процессов

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![height:450px center](images/workflows.png)

---

# GitLab

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![bg left:50% 100%](images/gitlab-mem.png)

GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD конвейером и другими функциями.

---

# Gitea

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![bg right:50% 170%](images/gitea-mem.jpg)

Gitea - ПО для хостинга IT-проектов и совместной разработки на базе Git. Поддерживает отслеживание ошибок, вики и обзора кода. Gitea поддерживает самостоятельный хостинг, но также существует и бесплатный сервис.

---

# GitFlic

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![bg left:50% 140%](images/gitflic-mem.jpg)

GitFlic - первый российский сервис для хранения исходного кода и работы с ним. Основан на системе контроля версий Git.

---

# Вопросы?

<style scoped>
p {
  text-align: center;
}
</style>

![height:430px center](../images/questions.jpg)

**If not, just clap your hands!**
